


# Kazoo（主流首选）​​
# ​​定位​​：官方推荐的 Python 客户端库，功能全面且稳定。
# ​​使用场景​​：
# 基础操作（节点增删改查、监听）。
# 高级功能：分布式锁、选举、队列、服务发现。
# ​​优势​​：
# 社区活跃，文档完善（官方及大量教程）。
# 被 Hadoop、Kafka 等知名项目间接使用。
# 支持异步 API 和连接状态监听。

from kazoo.client import KazooClient
zk = KazooClient(hosts='localhost:2181')
zk.start()
zk.create("/config", b"data")  # 创建节点
data, stat = zk.get("/config")  # 读取数据
zk.stop()




# ZooKeeper 严格遵循 ​​CP原则​​（一致性+分区容错性），在分布式协调场景中优先保证数据强一致性。然而，微服务注册中心的核心需求是 ​​高可用性（AP）​​：
# ​​Leader选举期间服务瘫痪​​：ZK集群在Leader宕机或网络分区时需重新选举，耗时 ​​30~120秒​​，期间整个集群不可用，导致服务发现功能中断
# 数据一致性 vs 服务连通性​​：微服务场景允许短暂的数据不一致（如服务列表延迟更新），但绝不能因注册中心自身故障导致服务调用失败。ZK的CP设计与此需求背道而驰。

# 磁盘I/O阻塞写操作​​：ZK所有写操作需同步磁盘日志，且默认​​阻塞后续请求​​直到写入完成，导致高并发下吞吐量骤降（典型TPS仅 ​​1万左右​​），远低于现代AP组件（如Eureka、Nacos）。
# ​​主从同步延迟​​：Leader需等待所有Follower确认写入才能响应客户端，网络波动会显著放大延迟。
# ​​无水平扩展能力​​：ZK集群扩容需手动重配置，无法通过简单增加节点提升性能。



# 健康检查机制不满足业务需求​​
# ZK的探活机制仅依赖 ​​TCP长连接状态​​，无法检测应用层健康（如服务过载、业务逻辑故障）。
# 👉 示例问题：服务进程存活但无法处理请求时，ZK仍将其标记为“可用”，导致流量误导向故障实例。